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Abstract 


Many  organizations  with  an  existing  process  improvement  initiative  are  also  considering 
software  product  line  adoption.  Managers  and  technical  leaders  in  these  organizations  often 
ask  how  they  can  build  on  their  process  improvement  work  and  reconcile  these  two 
significant  change  initiatives. 

This  technical  note  addresses  product  line  adoption  in  the  context  of  an  organization  that  is 
using  the  Capability  Maturity  Model®  Integration  (CMMI®)  models  to  guide  its  process 
improvement  effort.  Details  are  provided  to  show  how  selected  CMMI  process  areas  provide 
a  basis  for  certain  important  software  product  line  practices. 
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1  Introduction 


Software  process  improvement  (SPI),  based  on  the  quality  concepts  pioneered  by  Crosby 
[Crosby  79],  Deming  [Deming  86],  and  others,  has  been  a  widely  accepted  practice  for 
roughly  the  past  decade.  Articles  on  SPI  appear  regularly  in  technical  and  trade  journals 
[McConnell  02],  and  impressive  return  on  investment  (ROI)  figures  are  routinely  reported 
[Ferguson  99,  Goldenson  95,  Zahran  97].  More  recently,  many  organizations  are  finding  that 
the  practice  of  building  sets  of  related  systems  together  can  yield  remarkable  quantitative 
improvements  in  productivity,  time  to  market,  product  quality,  and  customer  satisfaction. 
These  organizations  are  adopting  a  product  line  approach  for  their  software  systems. 
Evidence  of  the  increased  benefits  achieved  when  a  product  line  approach  is  coupled  with 
SPI  has  been  particularly  exciting  [Vu  00]. 

Previous  technical  reports  written  by  the  Carnegie  Mellon®  Software  Engineering  Institute 
(SEI)  have  provided  the  following  information  relating  software  process  improvement  and 
software  product  line  initiatives: 

•  Jones  and  Soule  provide  background  on  both  the  Capability  Maturity  Model®  (CMMI®) 
models  and  A  Framework  for  Software  Product  Line  Practice, SM  and  a  broad  description 
of  the  support  CMMI  provides  for  product  line  practice  [Jones  &  Soule  02]. 

•  Jones  describes  how  typical  process  improvement  infrastructure  elements  could  be 
adapted  to  support  software  product  line  adoption  [Jones  04]. 

•  Northrop  provides  a  pattern-based  approach  to  software  product  line  adoption  [Northrop 
04], 

Building  on  those  reports,  this  technical  note  is  intended  to  provide 

•  linkage  among  these  previous  reports,  emphasizing  product  line  adoption  in  an 
organization  that  has  adopted  CMMI-based  process  improvement 

•  additional  information  on  CMMI  support  for  product  line  practice,  specifically  relating 
selected  CMMI  process  areas  to  certain  practice  areas  in  A  Framework  for  Software 
Product  Line  Practice 

•  a  brief  look  at  the  relationships  between  these  software  technologies  and  hardware 
engineering 


Carnegie  Mellon,  Capability  Maturity  Model,  and  CMMI  are  registered  in  the  U.S.  Patent  and 
Trademark  Office  by  Carnegie  Mellon  University. 

SM  A  Framework  for  Software  Product  Line  Practice  is  a  service  mark  of  Carnegie  Mellon  University. 
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Following  this  brief  introduction,  Section  2  gives  contextual  information  including  some 
fundamental  information  about  software  product  lines  and  the  CMMI  models.  Section  3 
describes  the  Adoption  Factory  pattern  that  provides  a  blueprint  for  product  line  adoption  in 
terms  of  product  line  practice  subpattems  and  examines  high-level  CMMI  support  for  that 
pattern.  Section  4  provides  more  detailed  information  on  how  a  process  improvement  effort 
based  on  CMMI  models  can  be  leveraged  in  product  line  adoption.  Section  5  summarizes 
this  report. 
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2  Background 


2.1  Process  Discipline  and  Software  Product  Line  Practice 

Software  engineering  process  discipline  has  a  significant  relationship  to  product  line  practice. 
Product  line  practice  is  strategic  in  nature.  A  strategic  effort  requires  more  coordination, 
discipline,  and  commonality  of  approach  than  a  more  independent  effort.  Dependencies 
within  an  organization  are  greater,  and  predictability  and  quality  become  even  more  critical. 
Process  discipline  can  provide  the  basis  for  a  strategic  effort  and  has  proven  that  it  can 
provide  better  predictability  and  quality.  Thus,  an  organization  with  a  culture  of  process 
discipline  is  much  better  poised  for  product  line  success,  and  there  is  a  distinct  overlap  of 
activities  between  software  process  improvement  efforts  and  software  product  line  efforts. 

Figure  1  summarizes  the  complementary  nature  of  software  engineering  process  discipline 
and  software  product  line  practice.  It  also  illustrates  a  “multiplier”  effect,  namely  that  the  two 
technologies  can  operate  in  concert  to  achieve  business  goals  through  a  complementary  focus 
on  both  process  and  product.  This  focus  makes  it  natural  to  extend  process  discipline  beyond 
just  the  engineering  processes  and  explicitly  brings  in  nontechnical  processes  and 
organizational  aspects  that  are  emphasized  in  A  Framework  for  Software  Product  Line 
Practice  but  to  a  lesser  extent  in  the  CMMI  models. 


Process-Product  Focus  to 
Achieve  Business  Goals 


Figure  1:  Process  and  Product  Line  Relationships 

Moreover,  many  of  the  activities  involved  in  software  engineering  process  improvement  have 
relevance  in  hardware  engineering.  For  example,  improved  requirements  management  in 
software  will  definitely  have  a  relationship  to  requirements  management  in  the  hardware 
associated  with  the  software.  Also,  many  of  the  software  product  line  practices  can  be 
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applied  to  hardware  in  the  case  where  the  systems  being  developed  involve  software 
embedded  in  hardware. 

Figure  2  illustrates  notionally  the  concept  of  the  overlap  among  hardware  engineering, 
software  process  improvement,  and  a  software  product  line  approach.  The  figure  is  not 
drawn  to  scale;  that  is  to  say,  it  depicts  overlap  but  not  degrees  of  overlap. 


Figure  2:  Overlapping  Activities 

If  a  business  is  involved  in  all  three  activities,  it  is  useful  to  understand  as  much  as  possible 
about  what  constitutes  the  overlap.  Sections  3  and  4  of  this  report  are  intended  to  shed  light 
on  that  topic. 

2.2  The  Software  Product  Line  Practice  Framework 

A  software  product  line  is  a  set  of  software-intensive  systems  sharing  a  common,  managed 
set  of  features  that  satisfy  the  needs  of  a  particular  market  segment  or  mission  and  that  are 
developed  from  a  common  set  of  core  assets  in  a  prescribed  way  [Clements  &  Northrop  02]. 
The  SEI  has  codified  the  essential  product  line  activities  and  practices  in  A  Framework  for 
Software  Product  Line  Practice  (henceforth  referred  to  as  the  Framework).  Version  4.0  of  the 
Framework  is  published  in  the  book  titled  Software  Product  Lines:  Practices  and  Patterns 
[Clements  &  Northrop  02].  Version  4.2  is  located  on  the  SEI’s  Web  site  [Clements  & 
Northrop  04]. 

The  Framework  describes  the  essential  practice  areas  for  software  engineering,  technical 
management,  and  organizational  management,  where  these  categories  represent  disciplines 
rather  than  job  titles.  A  practice  area  is  a  body  of  work  or  a  collection  of  activities  that  an 
organization  must  master  to  successfully  carry  out  the  essential  work  of  a  product  line.  The 
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software  engineering  practice  areas  include  those  practices  necessary  to  apply  the  appropriate 
technology  to  create  and  evolve  both  core  assets  and  products  as  follows: 

•  Architecture  Definition 

•  Architecture  Evaluation 

•  Component  Development 

•  COTS1  Utilization 

•  Mining  Existing  Assets 

•  Requirements  Engineering 

•  Software  System  Integration 

•  Testing 

•  Understanding  Relevant  Domains 

The  technical  management  practice  areas  include  those  management  practices  necessary  to 
engineer  the  development  and  evolution  of  the  core  assets  and  products  as  follows: 

•  Configuration  Management 

•  Data  Collection,  Metrics,  and  Tracking 

•  Make/Buy/Mine/Commission  Analysis 

•  Process  Definition 

•  Scoping 

•  Technical  Planning 

•  Technical  Risk  Management 

•  Tool  Support 

Organizational  management  refers  to  the  management  of  the  business  issues  that  are  visible 
at  the  enterprise  level,  as  opposed  to  those  at  the  project  level.  Organizational  management 
includes  those  practice  areas  necessary  to  position  the  enterprise  to  take  fullest  advantage  of 
the  product  line  capability.  The  organizational  management  practices  include 

•  Building  a  Business  Case 

•  Customer  Interface  Management 

•  Developing  an  Acquisition  Strategy 

•  Funding 

•  Launching  and  Institutionalizing 

1  COTS  stands  for  commercial  off-the-shelf. 
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•  Market  Analysis 

•  Operations 

•  Organizational  Planning 

•  Organizational  Risk  Management 

•  Structuring  the  Organization 

•  Technology  Forecasting 

•  Training 


2.3  Product  Line  Practice  Patterns 

The  SEI  also  defined  a  collection  of  product  line  practice  patterns  [Clements  &  Northrop  02]. 
Such  patterns  address  recurring  product  line  problems  that  arise  in  specific  software  product 
line  situations  and  present  solutions  to  them.  The  collection  of  12  patterns  and  11  variants 
characterize  common  product  line  contexts  and  problem/solution  pairs  that  we  have 
observed. 

The  product  line  practice  patterns  span  various  ranges  of  abstraction,  scale,  and  purpose.  The 
context  for  some  of  the  patterns  is  universal — that  is,  they  apply  in  all  situations.  The  context 
for  other  patterns  is  particular  to  specific  organizational  conditions.  Some  of  the  patterns  are 
related  in  that  they  solve  a  part  of  the  overall  software  product  line  approach  and  that  a 
pattern  hierarchy  makes  sense.  The  Factory  pattern  is  of  particular  interest  in  that  it  is  a 
composite  pattern  that  describes  the  entire  product  line  organization.  It  provides  a  picture  of 
what  an  organization  would  look  like  if  it  had  product  line  capability.  In  Section  3  we  will 
describe  in  detail  an  important  variant  of  this  pattern,  the  Adoption  Factory  pattern. 


2.4  CMMI  Models 

A  major  organizing  element  for  all  CMMI  models  is  the  process  area.  A  process  area  is  a 
group  of  related  activities  that  is  performed  collectively  to  achieve  a  set  of  goals.  A  process 
area  specifies  two  things:  (1)  goals  that  describe  the  result  of  successful  application  and  (2) 
practices  that  describe  the  required  (and  expected)  activities  to  achieve  those  goals.  Some 
goals  and  practices  are  specific  to  the  process  area;  others  are  generic  and  apply  across  all 
process  areas.  These  generics  describe  essential  ways  in  which  a  process  can  be 
institutionalized.  Institutionalization  refers  to  a  process’s  degree  of  repeatability, 
standardization,  and  sophistication  of  control. 

Structurally,  each  CMMI  model  comes  in  two  representations:  (1)  a  staged  representation 
and  (2)  a  continuous  representation.  These  two  representations  are  really  just  different  views 
into  the  same  content;  they  differ  in  how  they  organize  both  the  process  areas  and  the 
generics’  application  to  those  areas.  A  staged  representation  focuses  on  the  organization’s 
processes  as  a  whole,  provides  a  roadmap  for  process  improvement  with  proven  predefined 
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groupings  of  process  areas,  and  provides  an  easy  migration  path  from  the  CMM  for  Software 
(SW-CMM).  A  continuous  representation  focuses  on  improving  individual  process  areas 
chosen  to  align  with  specific  organizational  needs  and  provides  an  easy  migration  path  from 
Electronic  Industries  Alliance  Interim  Standard  (EIA/IS)  731  [Menezes  02]. 

Unique  to  the  staged  representation  is  the  major  organizing  element  of  the  maturity  level — an 
indicator  of  the  extent  to  which  a  set  of  processes  is  implemented  and  institutionalized. 
Maturity  levels  and  their  process  area  groupings  for  CMMI  for  Systems  Engineering, 
Software  Engineering,  Integrated  Product  and  Process  Development,  and  Supplier  Sourcing 
(CMMI-SE/SW/IPPD/SS)  are  shown  in  Table  1. 

Table  1:  CMMI-SE/SW/IPPD/SS  Staged  Representation  Process  Areas 


Level 

Focus 

Process  Area 

5  Optimizing 

Continuous 

Organizational  Innovation  and  Deployment 

Process 

Improvement 

Causal  Analysis  and  Resolution 

4  Quantitatively 
Managed 

Quantitative 

Management 

Organizational  Process  Performance 

Quantitative  Project  Management 

3  Defined 

Process 

Standardization 

Requirements  Development 

Technical  Solution 

Product  Integration 

Verification 

Validation 

Organizational  Process  Focus 

Organizational  Process  Definition 

Organizational  Training 

Integrated  Project  Management  for  IPPD 

Risk  Management 

Integrated  Teaming 

Integrated  Supplier  Management 

Decision  Analysis  Resolution 

Organizational  Environment  for  Integration 

2  Managed 

Basic  Project 
Management 

Requirements  Management 

Project  Planning 

Project  Monitoring  and  Control 

Supplier  Agreement  Management 

Measurement  and  Analysis 

Process  and  Product  Quality  Assurance 

Configuration  Management 

1  Initial 

N/A 

N/A 

The  continuous  representation  uses  the  concept  of  capability  level  to  measure  process 
improvement  within  individual  process  areas.  Capability  levels  represent  the  application  of 
the  generics  to  a  single  process  area  and  indicate  the  process  area’s  degree  of 
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institutionalization.  Apart  from  the  application  of  generics  to  an  individual  process  area, 
continuous  representation  models  do  not  recommend  a  particular  implementation  order.  Also, 
though  they  recognize  relationships  within  general  CMMI  categories  (see  Table  2),  the 
models  generally  treat  process  areas  as  independent.  While,  in  theory,  this  treatment  implies 
freedom  of  implementation  order  when  using  a  continuous  representation,  key  associations 
among  the  process  areas  preclude  totally  arbitrary  ordering  or  implementations. 


Table  2:  CMMI  Process  Area  Categories 


Category 

Process  Areas 

Process  Management 

Organizational  Process  Focus 

Organizational  Process  Definition 

Organizational  Training 

Organizational  Process  Performance 

Organizational  Innovation  and  Deployment 

Project  Management 

Project  Planning 

Project  Monitoring  and  Control 

Supplier  Agreement  Management 

Integrated  Project  Management  for  IPPD 

Risk  Management 

Integrated  Teaming 

Integrated  Supplier  Management 

Quantitative  Project  Management 

Engineering 

Requirements  Management 

Requirements  Development 

Technical  Solution 

Product  Integration 

Verification 

Validation 

Support 

Configuration  Management 

Process  and  Product  Quality  Assurance 

Measurement  and  Analysis 

Decision  Analysis  and  Resolution 

Organizational  Environment  for  Integration 

Causal  Analysis  and  Resolution 

Experienced  implementers  often  take  advantage  of  the  strengths  of  both  representations.  For 
example,  when  relying  on  a  staged  ordering  as  a  “first  cut”  prioritization,  you  might  vary  the 
basic  implementation  ordering  based  on  business  needs  or  “where  it  hurts  most.” 


Finally,  when  we  talk  about  CMMI-SE/SW/IPPD,  V  1.1  and  CMMI-SE/SW/IPPD/SS,  Vl.l, 
we  need  to  consider  that  the  model  implementation  now  extends  beyond  the  engineering 
organization  to  more  overtly  include  other  corporate  functions  such  as  procurement, 
marketing,  human  resources,  and  support  in  the  product  or  system  development  effort.  As  in 
the  characterization  of  the  Framework’s  organizational  implementation  that’s  described 
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above,  the  addition  of  these  domains  requires  a  strategic  understanding  of  the  ways  process 
improvement  affects  these  functions  within  the  organization.  Therefore,  most  of  the  attributes 
that  underpin  a  strategic  effort  such  as  product  line  management  (coordination,  discipline, 
commonality  of  approach,  etc.)  are  supported  by  a  robust  set  of  cross-functional  process  best 
practices  that  help  organizations  better  manage  dependencies  and  provide  for  improvements 
in  predictability  and  quality. 
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3  The  Adoption  Factory  Pattern  and  CMMI-Based 
Process  Improvement 


3.1  The  Adoption  Factory  Pattern 

The  Adoption  Factory  pattern,  shown  in  Figure  3,  is  a  variant  of  the  Factory  pattern 
[Northrop  04], 


Each  Asset 


l 


What  to  Build 


Process 

Definition 


-►  Prparts 1 - *■  Product  Builder 


Assembly  Line 


1 


I  I 


Cold  Start  In  Motion 


Monitor 


- ► 

Informs 

Figure  3:  Dynamic  Structure  of  the  Adoption  Factory  Pattern 

The  Adoption  Factory  pattern  can  be  used  as  a  generic  product  line  adoption  roadmap.  It 
provides  the  necessary  abstraction  of  the  major  activities  involved  and  their  dependencies.  In 
addition,  by  decomposing  the  pattern’s  subpattems  into  their  composite  practice  areas,  a  more 
detailed  adoption  plan  and  dependent  action  plans  can  readily  be  developed.  Even  though 
there  are  “informs”  relations  that  move  from  left  to  right  in  the  pattern’s  dynamic  structure, 
note  that  the  relations  in  the  product  line  practice  patterns  are  never  strictly  linear.  Owing  to 
the  highly  iterative  nature  of  product  line  adoption  and  operations,  the  arrows  should  always 
be  interpreted  as  denoting  a  shift  in  active  emphasis  but  by  no  means  exclusion. 

The  SEI  has  found  it  especially  useful  to  examine  the  Adoption  Factory  pattern  from  multiple 
views,  all  described  by  Northrop  [Northrop  04].  One  such  view  shows  phases  and  focus  areas 
simultaneously.  Figure  4  provides  this  perspective  with  the  appropriate  horizontal  focus  area 
delineations  and  the  vertical  phase  delineations. 
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Adoption 
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Figure  4:  Adoption  Factory  Pattern  Annotated  with  Adoption  Phases  and  Focus 
Areas 


The  detail  beneath  the  Adoption  Factory  pattern’s  subpattems  (as  articulated  by  the  practice 
areas  associated  with  each  one)  is  necessary  for  detailed  product  line  adoption  planning. 
Figure  5  shows  the  pattern  and  its  constituent  practice  areas  elaborated  in  a  view  that  also 
shows  the  focus  areas  and  adoption  phases. 
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Figure  5:  Adoption  Factory  Pattern  and  Its  Associated  Practice  Areas 

Notice  that  some  practice  areas  appear  in  multiple  phases.  However,  the  actual  practices  will 
vary  depending  on  the  phase  and  overall  objective  of  the  associated  pattern.  For  example,  the 
“Architecture  Definition”  practice  area  in  the  Establish  Production  Capability  Phase  is 
associated  with  the  Product  Parts  pattern  and  therefore  involves  defining  the  product  line 
architecture  that  will  be  the  structure  of  all  products.  The  “Application  to  Core  Asset 
Development”  section  of  the  “Architecture  Definition”  practice  area’s  description  in  the 
Framework  contains  relevant  guidance.  However,  the  “Architecture  Definition”  practice  area 
in  the  Operate  Product  Line  Phase  is  associated  with  the  Product  Builder  pattern  and 
therefore  involves  instantiation  of  product  architecture  from  the  product  line  architecture.  In 
this  case,  the  “Application  to  Product  Development”  section  of  the  “Architecture  Definition” 
practice  area’s  description  in  the  Framework  contains  relevant  guidance. 
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3.2  Relating  the  Adoption  Factory  Pattern  to  Hardware 
Engineering 

A  product  line  approach  to  software  was  inspired  by  product  line  approaches  in 
manufacturing.  Though  the  Framework  was  written  for  software  product  line  practice,  it  is, 
at  least  in  its  structure,  entirely  applicable  to  non-software  product  lines  or  to  the  hardware 
engineering  of  product  line  systems  that  are  combinations  of  software  and  hardware.  The 
essential  practice  areas  are  not  different,  but  how  they  apply  to  hardware  would  of  course  be 
different  from  how  they  apply  to  software.  In  terms  of  the  Adoption  Factory  pattern,  the 
greatest  areas  of  similarity  would  be  in  the  Organization  focus  area.  What  would  be 
accomplished  by  the  Cold  Start,  Monitor,  and  In  Motion  patterns  (and  hence  their  associated 
practice  areas)  would  be  virtually  the  same.  In  the  Process  focus  area,  there  is  also  overlap, 
but  the  actual  implementation  of  many  of  the  practice  areas  would  be  quite  different.  For 
example,  the  processes  and  tool  support  for  configuration  management  of  the  software  in  a 
product  line  would,  in  principle,  be  similar  to  that  for  the  hardware  but  would  be  different  in 
the  specifics.  The  greatest  departure  in  practice  area  implementation  would  occur  in  the 
Establish  Production  Capability  and  the  Operate  Product  Line  Phases  of  the  Product  focus 
area.  What  is  done  in  terms  of  defining  an  architecture  and  developing  components  would  be 
similar,  but  of  course  how  it  is  done  for  software  and  hardware  would  differ. 


3.3  The  Adoption  Factory  Pattern  in  a  CMMI-Based  Improvement 
Context 

Jones  and  Soule  provide  a  comparison  of  the  Framework  and  the  CMMI  models  [Jones  & 
Soule  02].  Included  in  that  comparison  is  a  table  (reproduced  below  in  Table  3)  that  draws 
some  high-level  associations  between  practice  areas  and  process  areas.  In  Table  2,  process 
names  in  bold  provide  “fairly  direct  support”  for  Framework  practice  areas,  while  others  are 
less  strongly  related. 
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Table  3:  Associations  Between  Software  Product  Line  Practice  Areas  and  CMMI 
Process  Areas 


Software  Product  Line  Practice  Areas  ( 

UMMI  Process  Areas 

Software  Engineering 

Architecture  Definition 

rechnical  Solution 

Architecture  Evaluation 

i/erification 

Component  Development 

rechnical  Solution 

COTS  Utilization 

Supplier  Agreement  Management 

Technical  Solution 

nteg  rated  Supplier  Management 

Mining  Existing  Assets 

N/A 

Requirements  Engineering 

Requirements  Development 

Software  System  Integration 

Product  Integration 

Testing 

Verification 

Validation 

Understanding  Relevant  Domains 

N/A 

Technical  Management 

Configuration  Management 

Requirements  Management 

Configuration  Management 

Data  Collection,  Metrics,  and  Tracking 

Measurement  and  Analysis 

Project  Monitoring  and  Control 

Integrated  Project  Management  for  IPPD 

Make/Buy/Mine/Commission  Analysis 

Decision  Analysis  and  Resolution 

Technical  Solution 

Supplier  Agreement  Management 

Integrated  Supplier  Management 

Process  Definition 

Organizational  Process  Definition 

Scoping 

N/A 

Technical  Planning 

Project  Planning 

Technical  Risk  Management 

Risk  Management 

Tool  Support 

N/A 

Organizational  Management 

Building  a  Business  Case 

N/A 

Customer  Interface  Management 

Integrated  Project  Management  tor  IPPD 

Integrated  Teaming 
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Table  3:  Associations  Between  Software  Product  Line  Practice  Areas  and  CMMI 
Process  Areas  (cont’d.) 


Software  Product  Line  Practice  Areas 

CMMI  Process  Areas 

Developing  an  Acquisition  Strategy 

Supplier  Agreement  Management 

Integrated  Supplier  Management 

Funding 

N/A 

Launching  and  Institutionalizing 

N/A 

Market  Analysis 

N/A 

Operations 

N/A 

Organizational  Planning 

Project  Planning 

Organizational  Risk  Management 

Risk  Management 

Structuring  the  Organization 

Organizational  Environment  for  Integration 

Integrated  Teaming 

Technology  Forecasting 

Organizational  Innovation  and  Deployment 

Training 

Organizational  Training 

Figure  6  shows  how  the  information  in  Table  3  impacts  the  Adoption  Factory  pattern  as 
shown  in  its  practice  area  view.  The  practice  areas  that  are  supported  by  a  CMMI-based 
improvement  effort  are  shown  in  italics. 


CMU/SE1-2005-TN-028 


15 


Establish 

Context 

Establish  Production 
Capability 

Operate 

*  Product  Line 

Product 

Marketing  Analysis 
Understanding  Relevant 
Domains 

Technology  Forecasting 
Building  a  Business  Case 
Scoping 

Requirements  Engineering 
Architecture  Definition 

Architecture  Evaluation 

Mining  Existing  Assets 
Component  Development 

COTS  Utilization 

Software  System  Integration 
Testing 

Requirements  Engineering 
Architecture  Definition  r» 

'  Architecture  Evaluation 

1  Mining  Existing  Assets 

1  Component  Development  €>K; 

1  COTS  Utilization 
|  Software  System  Integration 
|  Testing  i 

-  -  -  — 

_  -  -  -  -  -  - -  -  . - 

-  -  -  -  -  -  -  -  _ 

-  | -  -  -  -  -  -  -  -  - 

Process 

Process  Definition 

Make/Buy/Mine/Commission 

Analysis 

Configuration  Management 
Tool  Support 

Data  Collection,  Metrics, 
and  Tracking 

Technical  Planning 

Technical  Risk  Management 

1  '14 

i 

t 

i  •  • 

i 

-  -  -  -  — 

Organization 

Launching  and 
Institutionalizing 

Funding 

Structuring  the  Organization 
Operations 

Organizational  Planning 
Customer  Interface 
Management 
Organizational  Risk 
Management 

Developing  an  Acquisition 
Strategy 

Draining 

Launching  and 
Institutionalizing 

Funding 

Structuring  the  Organization 
Operations 

Organizational  Planning 
Customer  Interface 
Management 
Organizational  Risk 
Management 

Developing  an  Acquisition 
Strategy 

Training 

Data  Collection,  Metrics, 

1  and  Tracking 

1  Technical  Risk 
|  Management 
.  Organizational  Risk 
Management 

1  Customer  Interface 
|  Management 
|  Organizational  Planning 

1  .  Sjfj 

1  .  7 
| 

1  _ ___i 

Figure  6:  CMMI  Support  for  the  Adoption  Factory  Pattern 

It  is  not  surprising  that  the  greatest  leverage  is  in  the  Process  focus  area  of  the  Adoption 
Factory  pattern.  The  support  given  to  the  “Process  Definition”  practice  area  is  explained 
below.  A  detailed  description  of  the  support  provided  for  the  rest  of  the  italicized  practice 
areas  is  given  in  Table  4  located  in  the  next  section  of  this  report. 

The  “Process  Definition”  practice  area  is  about  an  organization’s  capability  to  define  and 
document  processes  [Clements  &  Northrop  02],  An  organization  needs  to  have  process 
discipline  to  succeed  with  a  software  product  line  approach  because  of  the  inherent  plurality 
of  the  products  and  of  the  groups  cooperating  to  develop  those  products.  A  software  product 
line  approach  will  work  only  if  everyone  does  his  or  her  job  within  agreed-upon  parameters. 
Because  product  lines  call  for  the  repeated,  ongoing,  disciplined  interaction  of  separate 
organizational  entities,  they  rely  heavily  on  the  adherence  to  a  process.  Process  definition 
represents  an  area  of  expertise  that  enables  many  other  practice  areas  to  be  executed 
successfully.  The  Process  pattern  [Clements  &  Northrop  02,  p.  386]  includes  all  the  other 
practice  areas  that  involve  defined  processes  and  that  consequently  rely  on  the  “Process 
Definition”  practice  area.  The  practice  areas  in  the  Process  pattern  are 
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•  Configuration  Management 

•  Data  Collection,  Metrics,  and  Tracking 

•  Process  Definition 

•  Operations 

•  Organizational  Planning 

•  Organizational  Risk  Management 

•  Technical  Planning 

•  Technical  Risk  Management 

In  addition,  the  Each  Asset  pattern  replicated  for  all  the  assets  in  the  core  asset  base  is  part  of 
the  Process  pattern  because  each  asset  in  the  core  asset  base  should  have  an  attached  process 
that  dictates  how  the  asset  will  be  used  to  produce  a  product  in  the  product  line.  Process 
definition  expertise  is  required  to  construct  these  attached  processes.  The  relationships 
among  the  elements  of  the  Process  pattern  are  shown  in  Figure  7  below,  which  depicts  the 
dynamic  structure  of  the  process  pattern. 


Informs  *for  each  core  asset 


Figure  7:  Dynamic  Structure  of  the  Process  Pattern 
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4  Details  on  CMMI  Model  Support  for  Software  Product 
Line  Practice 


4.1  Process  Area  Support  for  Selected  Practice  Areas 

Practice  areas  and  process  areas  are  fundamentally  different.  Even  when,  at  first  glance,  they 
appear  to  cover  the  same  topic,  similar  names  do  not  mean  they  cover  the  same  ground. 
Practice  areas  also  extend  the  realm  of  their  coverage  into  the  situation  where  product  lines 
are  the  goal,  which  is  not  the  focus  of  the  process  areas.  Just  because  an  organization  has 
institutionalized  the  CMMI  process  area  of  Configuration  Management,  it  does  not  mean  that 
that  organization  has  mastered  the  “Configuration  Management”  practice  area  for  software 
product  lines. 

Institutionalization  of  any  CMMI  process  provides  at  least  some  process  discipline  basis  for 
product  line  practice.  In  CMMI  terms,  institutionalization  involves  the  achievement  of  four 
goals  through  implementation  of  the  generic  practices  (GPs).  While  not  required,  some  GPs 
may  be  nicely  supported  by  implementing  certain  CMMI  process  areas,  in  particular:  Project 
Planning;  Project  Monitoring  and  Control;  Configuration  Management;  and  Organizational 
Training.  In  the  CMMI  model  staged  representation,  the  GPs  are  grouped  into  four  common 
features: 

1.  Commitment  to  Perform  groups  the  GPs  related  to  creating  policies  and  securing 
sponsorship. 

2.  Ability  to  Perform  groups  the  GPs  related  to  ensuring  that  the  project/or  organization 
has  the  resources  it  needs,  including  training. 

3.  Directing  Implementation  groups  the  GPs  related  to  managing  the  performance  of  the 
process,  managing  the  integrity  of  its  work  products,  and  involving  relevant 
stakeholders. 

4.  Verifying  Implementation  groups  the  GPs  related  to  higher  level  management’s  review 
and  objective  evaluation  of  conformance  to  process  descriptions,  procedures,  and 
standards. 


In  most  cases,  the  Framework  practice  areas  deal  with  practices  that  are  essential  for  any 
successful  software  development.  Thus,  the  Framework  begins  with  the  assumption  that  these 
basic  development  and  management  practices  are  fulfilled  by  the  organization  (or  at  least  that 
detailed  guidance  is  available  elsewhere),  and  then  it  identifies  practices  that  an  organization 
must  adopt  to  develop  and  manage  a  software  product  line  successfully.  In  those  cases  where 
CMMI  process  areas  align  with  the  Framework,  the  CMMI  defines  processes  in  terms  of 
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what  to  do,  and  the  Framework  provides  guidance  in  the  form  of  how  to  actually  do  a  related 
practice  to  support  software  product  lines. 

Organizations  that  plan  to  implement  product  lines  should  achieve  CMMI  capability  level  2 
(continuous  representation)  in  at  least  the  following  process  areas: 

•  Requirements  Management 

•  Project  Planning 

•  Configuration  Management 

•  Requirements  Development 

These  process  areas  will  give  the  necessary  capability  to  consider  achievement  of  the 
Assembly  Line  pattern.  Maturity  level  2  and  capability  level  2  generally  represent 
institutionalization  at  the  project  level.  Because  of  the  coordination  required  in  a  software 
product  line  approach  across  traditional  project  boundaries,  it  would  be  even  more  useful  to 
standardize  these  process  areas  at  the  organizational  level.  Doing  so  implies  achievement  of 
capability  level  3  for  these  process  areas. 

Figure  6  illustrated,  using  italics,  all  the  Framework  practice  areas  for  which  some  CMMI 
process  areas  provided  fairly  direct  support.  Jones  and  Soule  elaborate  on  what  the  phrase 
“fairly  direct  support”  means  for  the  “Configuration  Management”  practice  area  [Jones  & 
Soule  02].  Table  4  provides  a  similar  elaboration  for  the  other  italicized  practice  areas. 
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Table  4:  How  Framework  Practice  Areas  Are  Supported  by  CMMI  Process  Areas  (cont’d.) 
Framework  CMMI  Process  Area  CMMI  PA  Specific  Goals  (SGs)  and  Specific  Practices  (SPs)  Comments 
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Table  4:  How  Framework  Practice  Areas  Relate  to  CMMI  Process  Areas  (cont’d.) 

Framework  CMMI  Process  CMMI  PA  Specific  Goals  (SGs)  and  Specific  Practices  (SPs)  Comments 


O 

I  W  to  « 

!  S  2 

'  i  -  ” 

"3*1 

!  o  <0  3  — 

rs  s.8  |g  ® 

:  "O  o  m  X 

»  •>  ~  .-ts  2  ^ 

r  e  s  ®  o  ^ 

:  cl  w  w  5  -D 

:  <  Q>  «  &  2  « 

i  F5-S  |  f  “ 
i||8i-s 

>  E  E  “i  ro  co  o 
e  S’  o  a,  =  S 
O^CB.^W0- 
-  CO  <g  Q.  «  0)  o 

§E»t«o. 

> 

s  j|  ^  S  "c  "o 

cn  ^  o) 
^  eg  Q)  c-d  o 

13  w  rZ  .2  — 

5»8^|g 


O  13  CD 

CO  ^  O- 

•r  (0  O 

■g  E  » 

> 

to  £  £ 


o^o 

-Q  CO 
<0  C  CO 

.»  1  O 

S  E  2 
O  c  < 
□  o  ^ 

CO  ~  T3 
m  O  <D 
S  CD  CO 
CO  XI  3 


CD  P 

•*—  Q-  Q-  1 

C  (S  QJ  ! 

<D  x:  | 

g  °  o  ! 

CD  c  *—  ' 
O)  o  CO  ' 
<2  .<2  CO  : 
Cfl  CB  ' 
P  CL~ 

=  C  .>  • 

a >  k  r. 


2  ~ 

I  '2 

co  cl 

I.  5 

g*  £ 

E  "D 

c  .0) 

_C0  )*= 

Q.  C 

—  CD 

O  "O 

<D  — 

o'  a> 


5  <o  ^ 

s®  5 

-S  3  “ 

-o  .se  -o 


Q)  a  ^  -~ 

o>  TJ  "co 

e  S  o  ■— 

•g  §-  §  d  TO 

1 1  I 

P  CO  o  2  cz 

^  CO  CO  CL  ^ 

°  03  CD  CD  § 

!?££  8 


iS  = 

to  CO 
*_  o 

o  o  « 

”OQ) 
C  -C  3 
O  <d  CO 
S  CL  .52 


g  o« 
So  a 
O  P  <D 
O  q_£= 


04 

CO 

in 

cq 

-r- 

04 

CO 

'T“ 

T— ^ 

"T~^ 

*r~~ 

04 

04 

04 

04 

o 

CL 

CL 

CL 

CL 

CL 

Q_ 

CL 

O 

CL 

CL 

CL 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

g  -J§  -o  o 
<  8  §  & 

8§.-? 

•^=  VJ  o  ^ 

O  CO  C  o 

2  to  a>  £5 

OL  d^i — 


CMU/SEI-2005-TN-028 


Table  4:  How  Framework  Practice  Areas  Are  Supported  by  CMMI  Process  Areas  (cont’d.) 
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Table  4:  How  Framework  Practice  Areas  Are  Supported  by  CMMI  Process  Areas  (cont’d.) 

Framework  CMMI  Process  CMMI  PA  Specific  Goals  (SGs)  and  Specific  Practices  (SPs)  Comments 
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Table  4:  How  Framework  Practice  Areas  Are  Supported  by  CMMI  Process  Areas  (cont’d.) 

Framework  CMMI  Process  CMMI  PA  Specific  Goals  (SGs)  and  Specific  Practices  (SPs)  Comments 
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4.2  Leveraging  Process  Improvement  Infrastructure  to  Support 
Product  Line  Practice 

For  completeness  we  note  that  an  established  process  improvement  infrastructure  typically 
includes  at  least  the  following  elements: 

•  oversight  and  implementation 

•  process  assets 

•  a  training  infrastructure 

•  other  change  management  assets 

Each  of  these  elements  may  be  augmented  (or  emulated)  to  support  software  product  line 
practice.  Jones  gives  further  details  on  this  point  [Jones  04], 


CMU/SEI-2005-TN-028 


29 


5  Conclusion 


This  technical  note  provides  guidance  on  product  line  adoption  in  the  context  of  an 
organization  using  CMMI-based  process  improvement.  Additional  information  is  provided  if 
the  organization  also  develops  hardware  product  lines.  The  Adoption  Factory  pattern  was 
reexamined,  and  specific  support  for  product  line  practice  areas  through  CMMI  process  areas 
was  described.  While  there  is  certainly  more  room  for  exploration  of  connections  and 
specific  guidance  that  could  be  provided  to  business  units  in  their  product  line  efforts,  this 
report  should  provide  a  significant  start  in  that  direction. 

Software  engineering  process  discipline  as  specified  in  the  CMMI  models  provides  an 
important  foundation  for  software  product  line  practice,  and  there  can  be  a  uniformity  of  the 
general  approach  in  a  hardware/software  product  line.  It  is  always  the  case,  however,  that 
even  with  a  solid  process  foundation,  more  work  is  required  for  ultimate  success  with 
software  product  lines.  Success  in  software  product  lines  requires  mastery  of  many  other 
essential  practice  areas.  Also,  even  though  the  blueprint  provided  by  the  Adoption  Factory 
pattern  is  applicable  to  a  hardware  product  line,  the  implementation  of  the  practice  areas 
would  differ. 
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Appendix:  Acronym  List 


Acronym 

Definition 

COTS 

commercial  off-the-shelf 

CM 

configuration  management  in  the  context  of  a  CMMI  process  area 

CMG 

configuration  management  in  the  context  of  a  Framework  practice  area 

CMM 

Capability  Maturity  Model 

CMMI 

Capability  Maturity  Model  Integration 

CMMI-  SE/SW/ 
IPPD 

CMM  Integration  for  Systems  Engineering,  Software  Engineering,  and 
Integrated  Product  and  Process  Development 

CMMI-SE/SW/ 

IPPD/SS 

CMM  Integration  for  Systems  Engineering,  Software  Engineering, 
Integrated  Product  and  Process  Development,  and  Supplier  Sourcing 

DAR 

decision  analysis  and  resolution 

DCM 

data  collection,  metrics,  and  tracking 

EIA/IS 

Electronic  Industries  Alliance  Interim  Standard 

IPM 

integrated  project  management 

IPPD 

integrated  product  and  process  development 

GP 

generic  practice 

MA 

measurement  and  analysis 

MBM 

make/buy/mine/commission  analysis 

MSG 

management  steering  group 

OT 

organizational  training 

PMC 

project  monitoring  and  control 

PP 

project  planning 

RM 

risk  management 

SE 

systems  engineering 

SEI 

Software  Engineering  Institute 
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Acronym 

Definition 

SG 

specific  goal 

SP 

specific  practice 

SS 

supplier  sourcing 

SW 

software 

SW-CMM 

CMM  for  Software 

TPL 

technical  planning 

TRA 

training 

TRM 

technical  risk  management 

WBS 

work  breakdown  structure 
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